home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / Documents / Other / VirtualMemory.txt < prev    next >
Text File  |  1995-06-12  |  7KB  |  113 lines
  1.  
  2.  
  3. From: avie@next.com (Avadis Tevanian)
  4. Newsgroups: comp.sys.next.misc
  5. Subject: Re: Why does NS require so much Memory?
  6. Date: 6 Jun 1994 04:38:53 GMT
  7.  
  8. In article <1994Jun5.221433.24748@sifon.cc.mcgill.ca> samurai@cs.mcgill.ca
  9. (Darcy BROCKBANK) writes:
  10. > Oh well... can someone more informed than me
  11. > *please* take up this discussion, because I don't have
  12. > enough knowledge on this to come to the correct conclusion.
  13.  
  14. Here's the facts on how swapfiles work:
  15.  
  16. For every page in the swapfile, the kernel maintains status telling whether
  17. that page is in use or not.  When a swapfile it enabled (mach_swapon), it is
  18. truncated to lowat and each page is flagged as free.  When the page out daemon
  19. requests a page to be swapped out, the pager locates the first free page in the
  20. swapfile (actually, there is an algorithm to determine which swapfile is used,
  21. if more than one is enabled, but I will omit this from the discussion).  The
  22. first free page is defined as the lowest numbered page.  As more and more
  23. memory is consumed by processes, higher and higher numbered pages are used.
  24. When all pages in the swapfile are in use, and additional page out causes the
  25. swapfile to be extended in size.  This occurs until hiwat is reached.  If hiwat
  26. is reached, or if the file system is out of space, the page will be left in
  27. memory (unless there is another swapfile enabled that can be used).  If the
  28. system stays in this state, it will eventually be full of dirty pages which can
  29. not be paged out.  When this happens, the system comes to a grinding halt as it
  30. is forced to use fewer and fewer pages of memory (memory is filled with dirty
  31. pages that can not be paged out).
  32.  
  33. Now, it gets interesting when we consider what happens when memory is freed.
  34. In particular, when a process exits or calls vm_deallocate, the VM system
  35. attempts to free any memory that was associated with the appropriate regions of
  36. virtual memory.  When memory is shared, it simply makes a note that there is
  37. one fewer reference to the shared memory (or copy-on-written memory) and no
  38. further action is taken.  If this is the last reference to the memory, any
  39. corresponding physical pages are freed from main memory and any corresponding
  40. pages in the swapfile are tagged as free.  A subsequent allocation of page on
  41. the swapfile will most definitely reuse this page!
  42.  
  43. When a page is freed, if it is the highest page in the swapfile, the swapfile
  44. will be truncated all the way down to the highest page in use (down to lowat).
  45. In practice, this happens rarely.  The basic problem is that if you have a long
  46. running process use a very high number paged (e.g., if the Windowserver
  47. allocates a high numbered page) the swapfile will not get truncated until that
  48. process exits --- which could be a very long time.  When this happens due to a
  49. core process (e.g., the nmserver), which cannot be restarted unless the system
  50. is rebooted, your swapfile will remain large.  Still, there can be lots of free
  51. pages in the swapfile file, and rest assured they will be reused!
  52.  
  53. So why don't we compact the swapfile to handle these pages that get allocated
  54. at high page numbers?  Good question.  We've considered doing it many times.
  55. However, it has always been considered a quite risky change (how many of YOU
  56. have debugged a virtual memory system before) and would need to be done very
  57. carefully to ensure correctness and adequate performance.  As an example, it
  58. would not be acceptable to just start a compaction and cause the system to lock
  59. up as the kernel does several megabytes of I/O for the compaction.  The
  60. relative merits of making this improvement has never outweighted the costs in
  61. risk and the opportunity costs of not working on other parts of the system.
  62. I'm not saying we'll never do it, I'm just saying we haven't done it yet for
  63. some carefully considered reasons.
  64.  
  65. Having said all of this, why do so many people seem to have problems with their
  66. swapfiles?  Here are some possible explanations:
  67.  
  68. 1)  Not everyone realizes just how much memory their apps use.  As has been
  69. mentioned before, the Windowserver keeps backing store for all the windows (on
  70. or off screen).  On 16-bit color systems this can be quite large, on 24-bit
  71. systems its downright huge!  Simple images on the screen can translate into
  72. megabytes of storage.  Mathematica sessions are notorious for consuming 10's or
  73. even 100's of megabytes of VM.
  74.  
  75. 2)  Programs occasionally have memory leaks.  We work hard to be sure that the
  76. software we release does not have leaks.  There's a reason we developed
  77. MallocDebug!  I think we do pretty well, but I'm sure there are some bugs.  For
  78. example, the Windowserver, with it's printer heritage, has long had problems
  79. with correctly managing its memory.  On the printers they just "reset" the
  80. memory heap for each new job --- we can't do that.  If/when the Windowserver
  81. leaks we get a double whammy since not only do we leak a small amount of
  82. memory, but the Windowserver is a long running process and tends to hog those
  83. high numbered pages.  I think NEXTSTEP ISV's generally do a good job too, but
  84. it only takes one or two apps to leak memory and cause problems.
  85.  
  86. 3)  As many of you know, Mach has a quite advanced virtual memory scheme, which
  87. NEXTSTEP makes excellent use of.  Features like copy-on-write and pageable
  88. read/write sharing can cause complex relationships between memory and how it is
  89. mapped into one or more processes.  There is one known optimization that the
  90. kernel does (specifically the coalescing of adjacent memory regions when
  91. backing store has not yet been allocated --- for those of you Mach VM literate)
  92. which sometimes causes the freeing of some memory to be delayed until a process
  93. has exited.  The situations when this happens are fairly rare, and worse case
  94. the memory is freed when the process exits, but it wouldn't surprise me if this
  95. is the cause of isolated problems.
  96.  
  97. I personally think the Mach swapfile solution is quite good.  I'm obviously
  98. biased though.  Sure, there are a few things I think could be improved, but
  99. that's true of any piece of software.  Overall I think we've made some
  100. reasonable trade-offs.  I also think swapfile management is fairly bug-free.
  101. We know we can improve the situation is (3) above (but it is difficult).
  102. Certainly if anyone has any other possible reasons for swapfile growth,
  103. especially with concrete examples of programs, let us know so we can
  104. investigate!
  105.  
  106. I'd be more than happy to read suggestions others have on improving how
  107. swapfiles work.  I can't guarantee we'll implement them, but you never know!
  108.  
  109. I hope this sheds a little light on the whole swapfile discussion.  Somehow I
  110. think it will still continue on --- but hopefully it can be grounded with a few
  111. more facts now.
  112.  
  113.          Avie